[BugFix] Unschedule global RF timer in PipelineDriver destructor#76252
Conversation
|
@codex review |
A queued or blocked PipelineDriver that is abandoned when the driver executor
is closed during shutdown is destroyed without going through finalize(), which
was the only place the global runtime-filter timer (RFScanWaitTimeout) was
unscheduled. Because the bthread TimerThread keeps only a raw pointer to the
task, it can then fire on a task whose sole owning shared_ptr
(PipelineDriver::_global_rf_timer) is already gone. PipelineTimerTask::doRun()
calls shared_from_this() on that freed object and throws std::bad_weak_ptr,
aborting the process:
terminate called after throwing an instance of 'std::bad_weak_ptr'
RunTimerTask -> bthread::TimerThread::run
This is the abandoned-driver counterpart to the query-context-destruction race
fixed in StarRocks#73082, which only unscheduled from finalize(); the throwing
shared_from_this() in doRun() was introduced in StarRocks#72058.
Move the unschedule into a helper called from both finalize() and
~PipelineDriver(). The helper moves the shared_ptr into a local so the task
stays alive across unschedule_and_join(), closing the window where a
concurrently running doRun() could observe a zero use_count.
Add unit tests covering the destructor unscheduling a pending timer and the
destructor blocking until an in-flight timer task finishes.
Signed-off-by: Jenwit Amonpongitsara <jenwit.amonpongitsara@agoda.com>
b94e4bb to
2c184a5
Compare
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
[Java-Extensions Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[FE Incremental Coverage Report]✅ pass : 0 / 0 (0%) |
[BE Incremental Coverage Report]✅ pass : 7 / 7 (100.00%) file detail
|
|
@Mergifyio backport branch-4.1 |
|
@Mergifyio backport branch-3.5 |
|
@Mergifyio backport branch-4.0 |
✅ Backports have been createdDetails
Cherry-pick of b0363d9 has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
✅ Backports have been createdDetails
Cherry-pick of b0363d9 has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
✅ Backports have been createdDetails
Cherry-pick of b0363d9 has failed: To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally |
Why I'm doing:
A BE/CN aborts during shutdown with
std::bad_weak_ptr:The global runtime-filter timer (
RFScanWaitTimeout) is owned solely byPipelineDriver::_global_rf_timer, and it is only unscheduled infinalize(). Queued or blocked drivers that are abandoned when the driverexecutor is closed at shutdown are destroyed without going through
finalize(), so the bthreadTimerThread— which keeps only a raw pointer tothe task — can still fire on a task whose last owning
shared_ptris alreadygone.
PipelineTimerTask::doRun()then callsshared_from_this()on the freedobject and throws
std::bad_weak_ptr, aborting the process.This is the abandoned-driver counterpart to the query-context-destruction race
fixed in #73082, which unscheduled only from
finalize(). The throwingshared_from_this()indoRun()was introduced whenPipelineTimerTaskbecame
enable_shared_from_thisin #72058.What I'm doing:
_unschedule_global_rf_timer()and call it fromboth
finalize()and~PipelineDriver().shared_ptrinto a local so the task stays alive acrossunschedule_and_join(), closing the window where a concurrently runningdoRun()could observe a zerouse_count.destructor blocks until an in-flight timer task returns.
Verified: both changed translation units compile cleanly with the project
toolchain (gcc-12,
-std=gnu++23), zero diagnostics.What type of PR is this:
Does this PR entail a change in behavior?
Checklist:
Bugfix cherry-pick branch check: